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REMARKS 

Claims 1-19 are pending in this application. Claims 1-19 have been rejected. In view of 
the following remarks, the Applicants request allowance of the Application. 

Claim Rejections under 35 U.S.C, §102 

Burfoot Fails to Disclose A Read History as Recited in the Claims. 

To anticipate a claim, a reference must describe each and every element in the claim. 
See M.P.E.P. §2131. Claim 1 recites a system comprising, in relevant part: 

an analyzer to calculate an analytical result using at least one data entity stored 
in a database; and 

a data flow manager, responsive to read requests from agents to the 
database, to store a read history identifying a relationship between the 
data entity being read and the analytical result. 

Claims 9 and 14 recite similar features. The Examiner asserts that Burfoot discloses the recited 

data flow manager and correction server in his description of business logic and a calculation 

engine/spreadsheet peer, respectively. Applicants respectfully disagree. 

The Examiner asserts that Burfoot discloses the recited data flow manager and read 
history in a discussion of a "spreadsheet peer" transmitting data between a persistence layer 
and a client at paragraphs 33-38 and 46. However, the spreadsheet peer merely uses 
traditional synchronization techniques to maintain consistent data: 

[T]he peer must use appropriate synchronization techniques to ensure data is 
not modified concurrently by multiple client applications, and must make data 
commitments at appropriate times to ensure transactional integrity. 

H 0046 (emphasis added). While Burfoot's system may prevent concurrent data modification, 

there is no indication that it does so by logging or otherwise storing records of client access and 

a related analytical result. This is unsurprising, since Burfoot 's system prevents data 

inconsistency by restricting when data can be changed by the spreadsheet peer, not by 

tracking changes and accounting for inconsistencies at a later point in time. Thus, Burfoot fails 

to describe storing any read history, much less a read history identifying a relationship between 
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a data entity being read and an analytical result. For at least this reason, the claims are not 
anticipated by the cited reference. 

Burfoot Fails to Disclose a Corrections Server as Recited in the Claims. 

Claim 1 further recites, in relevant part: 

a corrections server that, when corrections are made to the database, identifies 
corrected entities in a corrected entity log and compares the corrected entity 
log against the read history to identify analytical results rendered possibly 
inconsistent due to the correction. 

Claims 9 and 14 recite similar features. Claim 19 recites a third database to store a list of 

uncorrected data entries identified as potentially inconsistent. The Examiner asserts that 

Burfoot discloses these features at paragraphs 0045-46. Applicants respectfully disagree. 

Burfoot merely describes a DSS server that performs calculations and provides the resulting 

values to clients. There is no suggestion that the DSS server or its calculation engine ever 

compares a corrected entity log to a read history or identifies possibly-inconsistent results 

resulting from a correction made to a database. 

It is unsurprising that Burfoot lacks a correction server, since his system has other 
techniques for maintaining data consistency. In Burfoot 's system, all calculations are performed 
by the DSS server, and clients are not allowed to make changes that might create inconsistent 
data: 

One idea that is particularly important to the concept of distributed spreadsheets 
is that the DSS server never serves a formula or reference, only a value. 
Therefore, it is necessary for the DSS server to be able to run spreadsheet 
calculations itself, and make those calculations before serving values. ... 
When the spreadsheet lookup subsystem finds the DSS object needed by a 
particular request, it invokes the spreadsheet peer to read the object from the 
persistence layer.. .the peer must use appropriate synchronization techniques to 
ensure data is not modified concurrently by multiple client 
applications, and must make data commitments at appropriate times to 
ensure transaction integrity. 

H 0045-46 (emphasis added). Thus, Burfoot avoids data inconsistencies by preventing 

concurrent modification by multiple clients. Nowhere does Burfoot suggest that the 

synchronization techniques used by the spreadsheet peer may fail or otherwise allow 

inconsistent analytical results. Burfoot simply has no need to identify analytical results that may 

be inconsistent due to a correction. Even if Burfoot 's technique could result in inconsistent 
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data, there is no indication of how Burfoot's system could subsequently identify such 
inconsistent data. Burfoot 's system fails to describe identifying analytical results rendered 
possibly inconsistent due to a correction or any similar feature and, therefore, fails to disclose 
each and every feature of the claims. For at least this reason, the claims are not anticipated. 

Burfoot Fails to Disclose the Features Recited in Claim 19. 

Claim 19 recites, in relevant part: 

a first database...; and 

a correction manager.. .comprising: 

a second database to store a list of corrected data entries in the first 
database; and 

a third database to store a list of uncorrected data entries identified 
as potentially inconsistent due to a correction performed on an entity 
listed in the second database. 

The Examiner asserts that Burfoot 's web server is the recited second database, and Burfoot 's 

persistence layer is the recited third database. This is incorrect. To anticipate the recited 

second database, Burfoot 's web server would have to store a list of corrected data entries in the 

first database. However, Burfoot lacks any indication or suggestion that the web server stores 

data at all. The web server merely passes information between clients and the rest of the DSS 

system: 

This component connects the system to the outside world. ..The web server 
connects to the business logic and passes the information sent to it from various 
clients. 

H 0040. 

Further, the differences between web servers and databases are well-known in the art, 
and are explicitly described in Burfoot : 

1. Persistence Layer. This is where the application stores the data that 
represents the spreadsheets. In many web applications, a relational database 
(RDBMS) is used for this purpose. Alternatively, the spreadsheets could be 
stored as simple files, preferably in an XML format. 

3. Web Server. This component connects the system to the outside world. A 
variety of web servers exist today, such as Apache and Microsoft Internet 
Information Server. 

H 0032, 0040. Burfoot does not suggest that his web server also functions as a database, and 
one of skill in the art would not interpret the described web server to be a database. 
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The Office Action also fails to show how Burfoot discloses the recited third database. 
According to the Examiner's analysis, Burfoot 's persistence layer would have to store a list of 
uncorrected data entries identified as potentially inconsistent due to a correction performed on 
an entity listed in a second database (the web server, as interpreted by the Examiner). Even if 
the web server stores the recited list of corrected data entries, which Applicants do not 
concede, there is no suggestion anywhere in Burfoot that the persistence layer stores a list of 
uncorrected entries based on the list of corrected entities. These features are simply absent 
from Burfoot 's disclosure. Thus, Burfoot 's system lacks at least the second and third databases 
as recited in the claims and, for at least this reason, fails to anticipate the claim. 

Further, to anticipate a claim a reference must disclose each and every element of the 
claim, and the elements must be arranged as required by the claim. SeeM.P.E.P. §2131 (citing 
In re Bond, 910 F. 2d 831, 15 USPQ 2d 1566 (Fed. Or. 1990). The Examiner interprets 
Burfoot 's business logic, web server, and persistence layer as the recited correction manager, 
second database, and third database, respectively. Claim 19 recites that the correction 
manager comprises the second and third databases. However, Burfoot 's business logic does 
not comprise or contain the web server and persistence layer. As shown by Burfoot 's Figure 1 
and as described in paragraphs 0031-38, the business logic, web server, and persistence layer 
are separate components of the DSS server. There is simply no indication that Burfoot 's 
business logic comprises a web server and a persistence layer, or that any similar configuration 
is possible in Burfoot 's system. Thus, the reference fails to disclose all the elements, arranged 
in the same way, as recited in the claim. For at least this reason, the reference fails to 
anticipate claim 19. 
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CONCLUSION 



All outstanding rejections have been overcome. It is respectfully submitted that, in view 
of the foregoing amendments and remarks, the application is in clear condition for allowance. 
Issuance of a Notice of Allowance is earnestly solicited. 

Although not believed necessary, the Office is hereby authorized to charge any fees 
required under 37 C.F.R. § 1.16 or § 1.17 or credit any overpayments to Deposit Account No. 
11-0600. 

The Office is invited to contact the undersigned at 202-220-4200 to discuss any matter 
regarding this application. 



Kenyon & Kenyon LLP 
1500 K Street, NW, Suite 700 
Washington, DC 20005-1257 
Tel.: (202) 220-4200 
Fax.: (202) 220-4201 



Respectfully submitted, 



Date: February 22, 2008 




Aaron S^Kamlay 
Registration No. 58,813 
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